Hi Jouke,

It's a follow up for already merged PR #206 . After we started to use paging, we found one issue with that old one PR. If initial query has parameters like page[number], etc, then it WebApi might encode them and then HttpRequestMessage.RequestUri would have already encoded one, and then links.self would have encoded value.

Here is what we are getting for endpoint that supports paging when we access such endpoint - https://localhost/WebService4/v5/internal/locations/marketplace?page[number]=2

{
    "data": [
        {
            "type": "marketplace-location",
            "id": "6927",
            "links": {
                "self": "https://localhost/WebService4/v5/internal/locations/locations/marketplace/6927/"
            },
            "attributes": {
                ...
            }
        }
    ],
    "links": {
        "self": "https://localhost/WebService4/v5/internal/locations/marketplace?page%5Bnumber%5D=1",
        "first": "https://localhost/WebService4/v5/internal/locations/marketplace?page[number]=0",
        "next": "https://localhost/WebService4/v5/internal/locations/marketplace?page[number]=2",
        "prev": "https://localhost/WebService4/v5/internal/locations/marketplace?page[number]=0",
        "last": "https://localhost/WebService4/v5/internal/locations/marketplace?page[number]=12"
    }
}

Here is what i'm seeing in Visual Studio in the debugger. I'm not sure why it happens in that way as initial url it totally correct and doesn't have any encoding.

I pushed fix to use _baseUrl.ToString() so it won't do encoding there and port also won't be present. And added a couple of tests to validate it. The problem there is that in unit test it doesn't do that so it's hard to mimic that behavior and only way i was able to do it by specifying already encoded _baseUrl in UrlConstructionTests.SelfLinkNoEncodingBasedOnEncoded unit test.

Thanks!